The term “engineering” used in the following implicates all possible actions in the context of software architectures of complex cyber-physical systems used in different technical domains, such as the maintaining of software architecture of complex cyber-physical systems.
The term “cyber-physical system” used in the following refers to a system of collaborating computational elements controlling physical entities (cf. http://en.wikipedia.org/wiki/Cyber-physical_system in the version of Jul. 23, 2014), whereby the technical domains may be as diverse as areas like aerospace, automotive, chemical processes, civil infrastructure, energy, healthcare, manufacturing, transportation, entertainment, consumer appliances, etc.
The term “software architectures” used in the following refers to a high level structure of a software system, the discipline of creating such a high level structure, and the documentation of this structure (cf. http://en.wikipedia.org/wiki/Software_architecture in the version of Jul. 24, 2014). Thus, when in the following the term “software architectures” is used all software structures of complex cyber-physical systems of different technical domains may be covered.
The architectural aspects of a large and complex cyber-physical system may be captured in a large number of system models called “Views”. Thus, when in the following the term “View” is used, the reader may have in mind that this term may replaced by the term “System Model” or the abridged term “Model” and vice versa, because both terms are synonymic. Views partition the system concerns into understandable chunks.
FIG. 1 depicts for example as prior art a Mechanical View M-VW, an Electronics View E-VW, a Functional View F-VW, and a Software View S-VW of such a complex cyber-physical system. According to the FIG. 1, a View VW include various Entities ENT, which are related to each other. The properties desired of the Entities are often modeled as Constraints, which are conditions that may be satisfied. Besides these intra-view Constraints (cf. the dashed lines in the FIG. 1) the Entities may also be related across various Views. In this case, we are talking about inter-view Constraints (cf. the solid lines in the FIG. 1). This implies, however, that the Constraints placed on the Entities in one View may affect the validity of the relations of the Entities in another View. It is a challenging task to make sure that these multi-view Constraints are never invalidated in the process of system engineering.
To better understand the problem, for example, the domain of safety integrity level analysis in the automotive domain is used.
In automotive engineering, the components of a system are assigned ASIL-numbers (Automotive Safety Integrity Level) to evaluate the risk of hazards posed by it. There are mandated, standard methods by which the ASIL-level of a combination of components is determined. This allows the architects to trace the ASIL-levels across the decomposition of the architecture of the system.
According to FIG. 2 as prior art, an example decomposition is as follows. Functional Views F-VWs of the architecture are derived from the requirements, which are then decomposed into constituent Logical Views L-VWs. The Logical Views L-VWs are then decomposed into Physical View P-VWs (Software Views and Hardware Views) depicting the actual physical components of the system.
Following the decomposition scenario according to the FIG. 2, in more detail, FIGS. 3A and 3B show as prior art two possible ASIL-decompositions with a violation of Safety-Constraints (FIG. 3A) and without a violation of Safety-Constraints (FIG. 3B). Considering a logical block P in the Logical View L-VW, if the logical block P is mandated to have the highest ASIL-level of D, it is allowed to be realized with redundant software implementation blocks having an ASIL-level of B(D). However, an ASIL-level of B(D) requires that the blocks may be functionally independent, that is, they do not affect the safety factors of each other.
What appears to be independent in the Software View S-VW of the system might erroneously be deployed on to the same processor in a Hardware View H-VW or the Physical View P-VW, thus violating the Constraint (cf. FIG. 3A). These efforts are to be considered to providing error-free system engineering (cf. FIG. 3B). Visual feedback of the Constraints being invalidated and the entities involved in the Constraints is also needed to make the system engineer's workflow more efficient.
With regard to such a method or tool for engineering or maintaining software architectures of complex cyber-physical systems of different technical domains, the following is provided.
Specialized tools for certain domains exist (e.g. Architecture Analysis & Design Language (AADL) is an architecture description language standardized by the Society of Automotive Engineers (SAE). AADL was first developed in the field of avionics (aerospace engineering) and was known formerly as the Avionics Architecture Description Language (cf. http://en.wikipedia.org/wiki/AADL in the version of Jun. 12, 2014), but are difficult to generalize, as well as don't offer support for automatic tracing or checking of multi-view Constraints. There are no tools that provide rapid visual feedback across architectural Views.
Thousands of Constraints need to be evaluated for a complex cyber-physical system. Yet, due to insufficient tool support for analyzing the architecture of a complex cyber-physical system, a majority of the safety analysis is done manually with office software like Excel and Word. Often only a single architectural decomposition is used to keep the scope of work tractable. Many person-hours of effort and review are used to provide that the evaluations are correct.
This situation results in very conservative design practices, as previously established architectures require less re-analysis. Design-space exploration (e.g. evaluating the realization of a requirement in hardware vs. software) becomes very tedious. As a result, very conservative deployments may be attempted in order to keep the safety analysis manageable. Optimization synergies are also not fully exploited due to the same reason.
Safety certification is an expensive part of system development, the cost of which depends on efficient safety analysis. Dynamic system architectures offer the possibility of creating products that may meet the changing needs of customers. However they are not economically feasible without some way of decreasing re-certification expenses.